CSRF(Cross-Site Request Forgery) 개념 및 실습

CSRF(Cross-Site Request Forgery) 개념 및 실습

Lecture
Security
태그
security
web
webhacking
public
완성
Y
생성일
Mar 28, 2024 12:10 PM
LectureName
Web Hacking

1. CSRF?


1.1 CSRF란

CSRF는 XSS를 통하여 발생하는 취약점으로 피해자의 권한으로 임의 주소에 요청을 보낼 수 있는 취약점입니다. 공격자는 XSS 취약점이 발생하는 페이지를 탐색하고, 해당 XSS페이지를 CSRF 페이로드로 디벨롭하여 피해자가 해당 페이지를 방문했을 때 원하지 않는 행동을 수행하도록 합니다.
 
 
 

1.2 명확히 해야 하는 부분

항상 해당 취약점을 해석할 때 판단이 어려운 부분이 있습니다. 그저 location.href 함수 등으로 해킹 사이트에 보내거나 다른 웹사이트로 보내는 것이 CSRF라고 봐야 하는가? 에 대한 판단입니다.
 
결론부터 말하자면 CSRF라고 보기 어렵습니다. 만약 해당 내용을 CSRF로 인정한다면 XSS가 터지는 거의 모든 부분에 CSRF가 동작할 확률이 높기 때문입니다.
 
🕵🏻 그래서 CSRF는 그럼 정확히 어떤 취약점이냐? 라고 한다면
  1. 대상 웹사이트에 XSS가 발생하는 곳이 있다.
  1. 사용자의 권한을 가지고 요청할 수 있는 페이지가 있어야 한다. (글쓰기, 조회, 삭제, 결제 등등)
  1. CSRF에 대한 방어대책이 존재하지 않아 XSS와 연계하여 해당 요청이 실행되어야 한다.
라고 할 수 있겠습니다.
 
💡
여기서 방어 대책이란?
CSRF에 대한 방어 대책으로, 웹페이지는 해당 요청이 사용자에 의한 요청인지 검사하여야 합니다. 예시로 다음과 같은 것들이 있습니다.
  • CSRF 토큰
  • Refer 검사
  • 2중 인증
 
 

1.3 주요 목적

피해자의 권한으로 할 수 있는 동작을 수행하는 것이 목표입니다.
 
 
 
 

2. 수행방법


2.1 예시 페이지

notion image
  • 다음과 같이 글을 작성할 수 있는 페이지가 존재합니다.
  • 작성자의 정보(닉네임)는 세션(쿠키)에서 가져오게 됩니다.
 
notion image
  • 글을 쓰게되면, 작성자만이 글을 수정하고 삭제할 수 있습니다.
  • 관리자가 작성한 공지사항은 상세보기를 할 수 없기 때문에 신뢰할 수 있는 게시글일 확률이 높습니다.
 
 
 

2.2 공격자가 관리자 아이디를 탈취한 후, CSRF 공격을 하는 시나리오

XSS 발생 가능한 곳 찾기
notion image
  • 관리자 아이디로 로그인에 성공한 공격자는, XSS가 발생하는 장소를 찾았습니다.
  • 공격자는 xss구문을 업그레이드하여 CSRF구문으로 만듭니다.
 
 
➡️이때 사용한 페이로드는 다음과 같습니다.
<form method="POST" action="/index.php?&page=board&model=write"> <input type="hidden" class="form-control" id="title" name="title" value="여긴 내가 해킹했다"> <input type="hidden" name="author" id="csrf" value=""> <textarea type="hidden" class="form-control" id="content" name="content" value="해킹 쉽다."></textarea> </form> <script> var author = document.getElementById("csrf"); author.setAttribute("value", document.getElementById("nickname").getAttribute("value")) document.forms[0].submit() </script>
  • 글을 강제적으로 작성하는 CSRF 페이로드입니다.
 
 
➡️ 페이로드가 담긴 글이 관리자의 이름으로 올라갔습니다.
notion image
  • 관리자가 올린 글은 참 중요해 보입니다.
  • 하지만 탈취된 관리자의 아이디로 공격자가 생성한 CSRF 트리거 페이지 입니다.
 
➡️ 그걸 모르는 사용자들은 CSRF 페이로드가 담긴 글을 클릭합니다.
notion image
  • 클릭과 동시에 글을 작성하게 됩니다.
 
 
➡️ 이후에 자신이 하지 않은 동작을 수행하게 되었습니다.
notion image
  • 웹페이지에 XSS, CSRF에 대한 방어 대책이 존재하지 않아서 사용자는 글을 클릭을 하였을 뿐인데 피해자의 이름(jalnik)로 "여긴 내가 해킹했다"라는 글을 쓰게 됩니다.
  • 해당 내용이 CSRF라고 보시면 됩니다.
여기서 중요한건 XSS가 터진건 VIEW 페이지고, CSRF에 취약한 페이지는 WRITE 페이지라는 것 입니다.
 
 
 

3. 방어 대책


3.1 원인 제거

CSRF는 반드시 XSS와 동반된다고 보면 됩니다. 물론 특이한 상황에서 HTML요소가 변경이 가능하여 요청값이 바뀐다던가 할수는 있지만 정말 특이한 상황을 제외하면 CSRF가 트리거 되려면 XSS와 함께하여야 합니다. 따라서 XSS에 대한 대비책을 강구하여야 합니다.
 
 

3.2 세부 방어대책

Referer 점검
  • 해당 요청을 하기 전 사이트의 origin을 검사합니다.
  • 예를 들어 게시판(/domain/board) 에서 (domain/money)를 요청하게 되면 referer에 /board가 남기 때문에 올바르지 않은 요청임을 알 수 있습니다.
하지만 해당 내용은 javascript를 사용한 CSRF의 경우 우회가 가능할 수 있습니다. (길이 제한이 없을 시)
 
 
CSRF 토큰 생성
  • 가장 보편적인 해결 방법입니다.
  • 서버에서 요청 페이지에 접속마다 알고리즘으로 짜여진 난수의 CSRF 토큰을 부여합니다.
  • 최종적으로 웹서버에 요청 시, 해당 토큰 값을 검증합니다.
 
 
캡챠
  • CSRF토큰과 유사하지만 약간 다릅니다.
  • 계산식, 글자맞추기, 그림 클릭하기 등 어떤 특수한 동작을 수행해야 요청에 성공할 수 있습니다.
  • 공격자는 캡챠를 우회할 방법을 찾지 못한다면 요청에 실패하게 됩니다.
 
 
2차 인증
  • 중요한 정보의 경우, 2차 비밀번호를 입력하게 할 수 있습니다.